A business process is a continuous series of enterprise tasks, undertaken to help create valuable output for an internal or external customer. A business process gives organizational actions structure across time, place, and/or functions. Business processes in general represent one way to describe, analyze, execute, and/or control operational structures across departments, business units, and/or even business partners. Business process management (BPM) relates to, inter alia, the continuous improvement of business processes, e.g., for the sake of overall business success. Amongst others, software-enabled business process automation is an instrument that may help increase efficiency and effectiveness of process execution. Business process models have been established to specify processes within BPM projects. For automation purposes, for example, business process models may help document and structure conceptual process requirements (business view) prior to their transformation into executable (code-based) specifications (technical view). Both modeling and transformation are typically involved in sound process automation.
With respect to business process modeling, it is noted that business process models typically describe the logical and timely flow of a business process in a map. They may, for example, help visualize process activities as graphical symbols and connect them to a linear order. Logical operators may indicate when the flow splits into alternative or parallel paths, when they merge into one again, etc. This so-called control flow typically is at the core of each business process model. It may be complemented by additional model elements that differ depending on the perspective. For instance, a conceptual-organizational perspective (business view) may target the organizational process context including intra- and inter-organizational division of labor, interaction between human activities, their technical support, product outcome, etc. The modeling language event-driven process chain (EPC) has prevailed as a de facto standard for such conceptual business processes. It complements process activities (business process steps) by organizational resources responsible, input required, output produced, etc., supporting software application systems, organizational objectives, risks, etc. While being rather easy to use even by non-technical process analysts, it does include important information on the logical flow, which makes it a semi-formal requirements basis for technical process implementation. It generally is at the transformation from conceptual into technical business process models where business process modeling changes the perspective from organizational design into technical engineering.
Business process transformation helps map the control flow described in a conceptual process model into a technical business process model. Here, it may be complemented by technical information, e.g., process variables for storing process information during execution, online forms for user interaction, exceptions and their handling, communication patterns (asynchronous/synchronous), consistent data exchange, etc. To make a process executable, process activities may be assigned to automated software functionality or to semi-automated user interfaces, or the like. Depending on the chosen modeling language and the targeted deployment system, this transformation may result in a second graphical diagram (e.g., BPMN 2.0, etc.) or directly into a code-based script (e.g., XPDL, BPEL, etc.). The resulting technical process models may be deployed into the process engine of a business process management system (BPMS) or workflow management system (WFMS), which allows for starting, executing, and tracking instances of the process efficiently.
Many recent transformation approaches add an intermediary model layer between conceptual process models (business view) and technical models (technical view). This so-called logical view sometimes provides notations in the technical modeling language (e.g., BPMN 2.0) but is not yet fully executable because of missing technical features. There are several advantages associated with this intermediary step. For example:                Conceptual processes may be mapped out in different tool environments rather than technical processes. The linguistic translation task thus may be complemented by a technical synchronization. Both tasks may be kept separated as much as possible to reduce complexity.        Conceptual processes may change more slowly than their technical implementation. Thus, there may be a benefit to a logical view that keeps track of the rather stable business requirements.        There typically are at least three business roles involved in the transformation activities. Each of them may have its own perspective and context.        Attempting to provide a tool-supported end-to-end solution between conceptual and technical processes may benefit from a bilateral synchronization level.        
FIG. 1 is a view of the three layers of business process automation. As can be seen from FIG. 1, at the requirements or business layer, the EPC captures business services capabilities. The EPC is transformed to BPMN, for example, for use at the design or logical layer. Systems and services technologies (SSTs), technical flows, and/or the like may be reflected in this second layer. The SSTs, technical flows, etc., may be packaged into deployable logic at the implementation or execution level. Executables may be represented in BPMN 2.0 or the like, and there may be a “roundtrip” connection between the design and implemental levels.
The idea of using business processes as blueprint for cross-application software systems is known from the concepts of workflow management systems (WFMS) and enterprise application integration (EAI). One factor that makes business process automation a technical challenge, however, is the plethora of heterogeneous and increasingly distributed software systems used for executing parts of the process. Those automated parts often further need to be integrated and connected along a given process flow, which enables their interoperability in the context of end-to-end business process automation.
Most recently, service-oriented architectures (SOAs) meet this integration challenge by exposing and integrating remote software functionality through well-defined software service interfaces. Early proponents thought of SOA as a specific style of distributed software architectures based on the so-called “find-bind-execute” relationship between service providers and consumers. More recent notions advance this integration view towards the potential SOA offers for business process automation and therefore helped position process automation into the center of the SOA discussion. The ability to compose services loosely opens new avenues to implementing business processes flexibly following dynamic business requirements. The adoption of standardized service interfaces allows for reusing services in different business processes, as well as flexibly replacing services according to evolving business requirements. In this sense, SOA has been considered as a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. Scientific discourse and best practices of service-oriented architectures provide a number of service-oriented design principles. While the SOA approach reinforces well-established, general software architecture principles of interface-orientation, interoperability, autonomy and modularity, it also adds additional themes of process-orientation. Thus, service-oriented design helps improve business process flexibility by the separation of process structure, e.g., process flow, and process institutionalization, e.g., selection of service capabilities conducting process activities.
Distilling requirements of business process systems based on typical properties of their elements and relationships reveals a high degree of polymorphy, that is, a multitude of possible variations and instantiations. Pursuing the same process objectives, multiple instances of a business process implementation are very likely to use different approaches and resources. This balance between homogeneous process requirements and heterogeneous ways to achieve this objective among different embodiments characterizes the concept of hybrid systems. The theory of hybrid systems helps describe systems that pursue a specific goal by deploying alternative subsystems based on runtime evaluation.
The notion of hybrid systems has gained public attention in the domain of car manufacturing, where hybrid vehicles are considered vehicles that use two or more distinct energy sources or propulsion devices to move the vehicle. Hybrid electric vehicles combine internal combustion engines and electric motors to attempt to strike a balance between ecological and dynamic aspects of driving. In information systems (IS) research and related disciplines, hybridity has been attributed to specific information systems, algorithms, and computing devices, as well as of business and organizational strategies. As with the hybrid vehicle example, hybrid information systems combine different approaches, promising “the best of both worlds.” This combination of distinct approaches helps ripen situational benefits and compensate for situational drawbacks. In business processes, diverse technical and human resource capabilities may also represent those alternative subsystems (socio-technical hybridity).
IS scholars generally agree on features that may be utilized to justify a classification of business process systems as hybrid systems. These attributes of those subsystems are to be combined by the hybrid system at runtime to achieve a common goal, and include:                Heterogeneous concepts that differ from each other in their characteristics or behaviors. Concepts are differentiated by certain criteria that assign properties to each concept. In a business process system, those subsystems are sub-processes or resources that provide different approaches to solve a problem or deliver a task. These sub-processes vary in their degree of automation, availability, cost, etc. (structural properties), and their modus operandi (behavioral properties).        Competitive concepts that are at odds with each other. While being heterogeneous in nature, they compete for a common cause, namely, the fulfillment of the system's purpose. In a BPS, a given process flow of activities may be institutionalized by various rivaling means. Rivalry may relate to cost, availability, expected costs, expected time a sub-process or resource promises to deliver (structural and behavioral properties), etc. To identify competing entities, their purpose is included into their property description (e.g., a purpose property).        Coexistent concepts whose dialectic forms continue to exist side-by-side, despite their apparently conflicting nature. They jointly serve a common cause while being alternated according to situational circumstances. In a BPS, diverse process resources may hold redundant capacities to deal with diverse business situations and requirements.        
Each of those heterogeneous, competitive, and coexistent subsystems provides an autonomous approach to fulfill the overall BPS purpose. Opposed to this heterogeneity are homogeneous rules that coordinate subsystems in the total system. This coexistence of heterogeneity and homogeneity is an integral pattern of hybrid systems. Thus, hybridity provides a design approach to integration problems in distributed, heterogeneous information systems. Today's web-based technologies allow distributed resources to participate in a shared collaborative process. Each of those resources holds technical or human capabilities. Design methods supporting a BPS provide answers to the question as to which of those diverse and partly redundant capabilities are deployed for a specific use case. Evaluation, selection, and exchange of alternative subsystems during runtime involve an additional phase complementing traditional system design logic of design time and runtime. During this so-called configuration time, the system purpose and system alternatives are aligned by continuous adaptation interrupting runtime as little as possible. Thus, the modeling and execution of business processes are converging in those configurative design activities. They allow recognizing situational circumstances immediately.
There are a number of software vendors that market transformation functionalities of their BPMS offerings. While most of them target service-oriented process automation, it is believed that none of them considers the implications of service-oriented business process systems being hybrid systems and it is also believed that none of them provided for configurational modeling.
Current commercially available products address the issue of service configuration in different ways. In a majority of cases, it is believed that a one-to-one mapping between process steps and software services is assumed and documented already at design time (static service deployment). There are a few approaches that consider dynamic human service deployment (task assignment) at runtime, but they do not provide for configurational activities at design time, such as service matching. None of the existing products is believed to facilitate logically connecting service matches based on their contribution to the respective business process step.
It is noted that transformation (both mechanisms and governance support) from conceptual to technical process models still is considered cutting-edge technology, specifically given complexity of real-world process models and organizational settings. Only few commercially available BPMS software products offer full support. Given this limitation, they lag behind any further, more sophisticated implementation of matching business requirements with available services. If anything, they provide search functionalities for services based on functional parameters (capabilities, input/output). Not only is there no more elaborate matching functionality available (because of the lack of richer service description standards), further support for handling service matching results, their dependencies, and contribution to the business requirements, also are lacking. As for dynamic service selection, e.g., automated or manual during runtime, there is a broad support for human task-related assignments (because of the issue of task delegation in human workflows), but none for software-service deployment.
While some research approaches involve some singular concepts that contribute to closing the gap between specification of business-oriented process steps and their execution through invoking services, the inventor of the instant application is not aware of any that actually provides end-to-end support for the same. For example, although vom Brocke introduces disjunctive operators to represent logical dependencies between service matches and mentions the concept of configurational modeling, his approach fails to distinguish diverse configurational operators and to elaborate on possible resolution techniques before process execution. Indeed, it has not been integrated into a business process transformation process and, thus, it fails to connect service-oriented process configuration with the runtime of BPMS. It also does not elaborate on all possible varieties of configurational dependencies between service matches. Thus, it misses the use cases of service composition and dynamic service selection.
In general, current approaches assume a one-to-one assignment between process steps and software services, neglecting any more realistic n-to-m relationship. As a consequence, there is no support for keeping track of multiple supportive services and their logical dependencies. Missing any preceding design decisions makes it difficult to support dynamic service deployment on-the-fly.
Thus, it will be appreciated that there is a need in the art for improved service-oriented process configuration techniques, e.g., that help connect service-oriented process configuration with the runtime of BPMS. Such techniques may advantageously help keep track of multiple supportive services and their logical dependencies (e.g., in connection with a more realistic n-to-m relationship between process steps and software services) so as to support dynamic service deployment both in the future and on-the-fly.
One aspect of certain example embodiments relates to matching business requirements with available services, e.g., in connection with a more realistic n-to-m relationship therebetween.
Another aspect of certain example embodiments relates to identifying and resolving configurational dependencies between service matches so as to support both future designs and dynamic changes at runtime.
Still another aspect of certain example embodiments relates to distinguishing between diverse configurational operators and elaborating on possible resolution techniques before process execution, e.g., in the context of an integrated business process transformation process, so as to help connect service-oriented process configuration with the runtime of a BPMS.
In certain example embodiments, a method of configuring a service-oriented business process system in which business process functions, events and services are defined is provided. Business process functions are matched to services to form an extended event-driven process chain (eEPC), with each said service having an associated service capability and with each said service capability having at least one associated service resource. When multiple matches are possible for a single business process functions, the possible matches are merged in accordance with a configurational operator, with the configurational operator being one of a disjunctive operator, a conjunctive operator, and an adjunctive operator. The eEPC is converted to a service-oriented event-driven process chain (sEPC) by replacing service capabilities with the associated matching services and the associated configurational operator in accordance with integrity rules.
In certain example embodiments, a method of running a service-oriented business process system in which business process functions, events and services are defined is provided. The service-oriented business process system may be configured according to the above-described and/or other methods. When a business process function is to be triggered by a preceding event, the matching service is executed if there are no associated configurational operators and otherwise resolving which service is to be executed in dependence on the associated configuration operator.
In certain example embodiments, there are provided non-transitory computer readable storage mediums tangibly storing instructions that, when executed by at least one processor of a system, perform the above-described and/or other methods.
In certain example embodiments, the same or similar systems may be provided in addition or in the alternative to such example methods and/or storage mediums.
These aspects and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.